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W henever I go to a conference and I discover that there will be 
a presentation about Byzantine fault tolerance, I always feel 
an immediate, unshakable sense of sadness, kind of like when 
you realize that bad things can happen to good people, or that Keanu Reeves 
will almost certainly make more money than you over arbitrary time scales. 
Watching a presentation on Byzantine fault tolerance is similar to watch- 
ing a foreign film from a depressing nation that used to be controlled by the 
Soviets— the only difference is that computers and networks are constantly 
failing instead of young Kapruskin being unable to reunite with the girl he fell 
in love with while he was working in a coal mine beneath an orphanage that 
was atop a prison that was inside the abstract concept of World War II. “How 
can you make a reliable computer service?” the presenter will ask in an inno- 
cent voice before continuing, “It may be difficult if you can't trust anything 
and the entire concept of happiness is a lie designed by unseen overlords of 
endless deceptive power ” The presenter never explicitly says that last part, 
but everybody understands what's happening. Making distributed systems 
reliable is inherently impossible; we cling to Byzantine fault tolerance like 
Charlton Heston clings to his guns, hoping that a series of complex software 
protocols will somehow protect us from the oncoming storm of furious apes 
who have somehow learned how to wear pants and maliciously tamper with 
our network packets. 
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Figure 1: Typical Figure 2 from Byzantine fault paper: Our network protocol 
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Every paper on Byzantine fault tolerance contains a diagram 
that looks like Figure 1. 

The caption will say something like “Figure 2: Our network 
protocol” The caption should really say, “One day, a computer 
wanted to issue a command to an online service. This simple 
dream resulted in the generation of 16 gajillion messages. An 
attacker may try to interfere with the reception of 1/f of these 
messages. Luckily, 1/f is much less than a gajillion for any rea- 
sonable value of f. Thus, at least 15 gajillion messages will sur- 
vive the attacker’s interference. These messages will do things 
that only Cthulu understands; we are at peace with his dreadful 
mysteries, and we hope that you feel the same way. Note that, 
with careful optimization, only 14 gajillion messages are neces- 
sary. This is still too many messages; however, if the system 
sends fewer than 14 gajillion messages, it will be vulnerable to 
accusations that it only handles reasonable failure cases, and 
not the demented ones that previous researchers spitefully intro- 
duced in earlier papers in a desperate attempt to distinguish 
themselves from even more prior (yet similarly demented) work. 
As always, we are nailed to a cross of our own construction.” 

In a paper about Byzantine fault tolerance, the related work 
section will frequently say, “Compare the protocol diagram of 
our system to that of the best prior work. Our protocol is clearly 
better.” The paper will present two graphs that look like Figure 2. 

Trying to determine which one of these hateful diagrams is 
better is like gazing at two unfathomable seaweed bundles that 
washed up on the beach and trying to determine which one is 
marginally less alienating. Listen, regardless of which Byzantine 
fault tolerance protocol you pick, Twitter will still have fewer 
than two nines of availability. As it turns out, Ted the Poorly 
Paid Datacenter Operator will not send 15 cryptographically 
signed messages before he accidentally spills coffee on the air 
conditioning unit and then overwrites your tape backups with 
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bootleg recordings of Nickelback. Ted will just do these things 
and then go home, because that’s what Ted does. His extensive 
home collection of “Thundercats” cartoons will not watch itself. 
Ted is needed, and Ted will heed the call of duty. 

Every paper on Byzantine fault tolerance introduces a new kind 
of data consistency. This new type of consistency will have an 
ostensibly straightforward yet practically inscrutable name 
like “leap year triple-writer dirty-mirror asynchronous semi- 
consistency.” In Section 3.2 (“An Intuitive Overview”), the 
authors will provide some plainspoken, spiritually appealing 
arguments about why their system prevents triple-conflicted 
write hazards in the presence of malicious servers and unex- 
pected outbreaks of the bubonic plague. “Intuitively, a malicious 
server cannot lie to a client because each message is an encrypted, 
nested, signed, mutually- attested log entry with pointers to 
other encrypted and nested (but not signed) log entries.” 

Interestingly, these kinds of intuitive arguments are not intui- 
tive. A successful intuitive explanation must invoke experiences 
that I have in real life. I have never had a real-life experience 
that resembled a Byzantine fault tolerant protocol. For example, 
suppose that I am at work, and I want to go to lunch with some of 
my co-workers. Here is what that experience would look like if it 
resembled a Byzantine fault tolerant protocol: 

JAMES: I announce my desire to go to lunch. 

BRYAN: I verify that I heard that you want to go to lunch. 

RICH: I also verify that I heard that you want to go to lunch. 

CHRIS: YOU DO NOT WANT TO GO TO LUNCH. 

JAMES: OH NO. LET ME TELL YOU AGAIN THAT I WANT 
TO GO TO LUNCH. 

CHRIS: YOU DO NOT WANT TO GO TO LUNCH. 
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Figure 2: Our new protocol is clearly better. 
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BRYAN: CHRIS IS FAULTY. 

CHRIS: CHRIS IS NOT FAULTY 

RICH: I VERIFY THAT BRYAN SAYS THAT CHRIS IS 
FAULTY 

BRYAN: I VERIFY MY VERIFICATION OF MY CLAIM THAT 
RICH CLAIMS THAT I KNOW CHRIS. 

JAMES: I AM SO HUNGRY. 

CHRIS: YOU ARE NOT HUNGRY. 

RICH: I DECLARE CHRIS TO BE FAULTY. 

CHRIS: I DECLARE RICH TO BE FAULTY. 

JAMES: I DECLARE JAMES TO BE SLIPPING INTO A 
DIABETIC COMA. 

RICH: I have already left for the cafeteria. 

In conclusion, I think that humanity should stop publishing 
papers about Byzantine fault tolerance. I do not blame my fellow 
researchers for trying to publish in this area, in the same limited 
sense that I do not blame crackheads for wanting to acquire and 
then consume cocaine. The desire to make systems more reliable 
is a powerful one; unfortunately, this addiction, if left unchecked, 
will inescapably lead to madness and/or tech reports that con- 
tain 167 pages of diagrams and proofs. Even if we break the will 
of the machines with formalism and cryptography, we will never 
be able to put Ted inside of an encrypted, nested log, and while 
the datacenter burns and we frantically call Ted’s pager, we will 
realize that Ted has already left for the cafeteria. 
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